Why are we using file size here for the loop? Is it to identify files that are symlinks?
If so, we can do so by using the -L test to determine whether it is a symbolic link.

Example:

RUN echo "$version-$module" | grep -q -vP '^(2022.[2-9]|202[3-9]|20[3-9]).*android' \
  && exit 0 \
  || : \
  && . ~/.bashrc \
  && cd "${ANDROID_NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64/bin" \
  && for f in *; do \
       if [ -L "$f" ]; then \
         target=$(readlink "$f") && echo "Making symlink $f -> $target" && rm "$f" && ln -s "$target" "$f"; \
       fi \
     done

I haven't tried this

So the files aren't actually symbolic links, they're a mix of ascii and binary files but inside they have the file name of the executable they should point to. We suspect hub isn't using the proper flags when unzipping so the symbolic links get lost hence the need for us to make the links ourselves.

Possibly more manageable to separate that part into a different PR? Not sure though. And not preference from my side.

This was the main point of the PR to fix the android build issues of 2022.2+ so I'm inclined to keep this as a single PR.

Yea, makes sense!

For other reviewers:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes

Default is 360, reducing it to 10 will most likely make it fail faster if necessary 👍

This is only a valid setting if you know the maximum amount a project would take to build. Useful for this repo. Perhaps also worth documenting in our docs for GHA?

In general you don't really need this setting. I think what is happening is these big matrices of Unity test runs exceed some kind of rate limit for activation endpoint silently which causes it to hang. I just set it to 10 minutes because I saw every test run with our empty test project takes about 1 min so by 10 min it's probably hung and guaranteed to fail. This time is heavily driven by the actual tests and whether the library folder already exists. The activation errors are also generally rare in standard CI runs.

There are in fact a few cases where implementers of GameCI using GHA are waiting for their run and they report it times out after 5 hours not knowing the error.

Probably the fastest way to setup GameCI (in case anything goes wrong) is to set it up using a test project, and having that setting set to 5 minutes :) Just a suggestion though.

Possibly more manageable to separate that part into a different PR? Not sure though. And not preference from my side.

Why remove the version flag? Is the argument no longer valid?

It actually wasn't relevant from the start. Reading more into the readme for the chocolatey package, Unity doesn't store an archive of the older Unity hubs so it will always pull the latest version. The chocolatey script used a hard coded hash for each version to verify the download so putting an older version can cause errors during installs.

They must have changed that. I wouldn't have added this param without it being documented.
Nice catch!